What kind of value does this test provide us beyond being great for this review?

It's an input error, not necessarily a contract we're going to try to maintain.

The input error is "by design". So you either handle the input error (I did not change this),
or you have a test proving it does what you found it does. It also helps someone see this code depends on non-null versions

Then, you have a test that can be easily flipped if/when we decide on a different design. Most of the test work is done, and the PR will be more clear.

Why did you decide against adding an input check?
Will the call always fail if the input PackageIdentity has a null version?

Because I'm trying to fix a bug specifically. Not redesign the inners of Package Manager.
Not always, nope. Has to be BuildIntegrated project, with at least 1 update available.

Because I'm trying to fix a bug specifically. Not redesign the inners of Package Manager.

I think this can be considered in scope.
Changing the NuGetPackageManager class to ensure we don't run into unexpected exceptions is in scope.
Especially because there wouldn't be any side-effects.

Especially because there wouldn't be any side-effects.

I don't have proof of that. And it's a 16.9 blocking bug, so not the time to start paying our debts. I think as part of 16.10 refactoring, this could be evaluated.

Synced up offline.

Call it good for 16.9, consider additional quality improvements in NuGetPackageManager for 16.10.